Games of Daze

home *** CD-ROM | disk | FTP | other *** search

/ Games of Daze / Infomagic - Games of Daze (Summer 1995) (Disc 1 of 2).iso / x2ftp / msdos / pmode / 386p_200 / xvd.txt < prev next >

Wrap

Text File | 1995-01-10 | 13.5 KB | 269 lines

XVD XGE Video Driver Release 0 Specification by Lorenzo Micheletto While devenloping XGE 2.00, one of my targets was to add more flexibility to the hardware specific subsystems. So i looked at what i was doing and where the hardware dipendence could be bound. Chapter I: THE XVD INTERFACE An XVD driver as defined in release 0 of the XVD specification is a very minimalist thing, just the routines needed to check for the graphics card, set the video mode and execute paging/video-ram-allocation. Initially i planned to devenlop very complex drivers capable to "take over" lots of higher level function if needed but to do this i needed a "link while the program is running" module to "link-in" the driver code (very complex) and this "autolinker" could not restrict with safety the driver's actions (imagine a driver conceived for "cracking specific programs" or worse) so i decided to use very minimalist drivers that could be linked as they was. As a side effect of this, an XVD TYPE ZERO driver is usually less than one Kbyte long. The 386video module just checks for XVD.XVD, loads it into memory and fix-ups some offsets to complete the code/data relocation. As i said the driver has only to check for video card, set the graphics mode perform display-start, set-cpu-window and paletter read/write functions. All the other things (blitting, page update methods etc. etc.) are up to the 386video module and all the other related to graphics. Chapter II: DRIVER SETUP (the most critical thing) The XVD drivers can be loaded and linked "on the run", they don't need to be distributed with your program because they can be added later to an existing game, so it is critical to use a consistent method for NAMING and INSTALLATION of "external" drivers. My proposal for STANDARD XVD DRIVER SETUP is the following: A) Your SETUP PROGRAM should search ( first in the current directory and then in the path contained into the XVD_PATH environment string) all the *.XVD files and list them in the video card selection list showing the descriptive strings contained into them. (description, author/s , release date) The setup program will COPY the selected driver to the game directory giving to the NEW file containing the driver the name XVD.XVD The setup program can be integrated into the main program or be an external program, anyway the "game code" doesn't have to mess with XVD_PATH or strange names, if for example it needs a 320x200 mode it only knows it has to search into the current directory a thing called XVD.XVD and to check if it can handle it. There must always be a "statically linked" driver into the game code (i use a 320x200 generic vga driver), but if the program sees into the current directory an external xvd driver it must load it ( the included driver has to be used only if there are no available drivers). Following this method it is possible to let a game support multiple resolutions keeping in memory only the driver in use and letting simple driver updating. What's more you can devenlop a game including support for only the standard vga and your specific video card, other drivers will be available as public domain or included with other games. IF YOU DEVENLOP AN XVD DRIVER, YOU SHOULD DISTRIBUITE IT AS PUBLIC DOMAIN AND WITH SOURCE INCLUDED (but you are free to ask to be payed for it). If ypu support free distribution, you will help make XVD a standard and so more games will use your graphics card to the max, and if you don't like the video driver somebody gave you, YOU WILL BE ABLE TO CUSTOMIZE IT!!!! You may think "Heck! I spent some time making this driver i want to be payed for this!", well, your name will be known, isn't it a good reward ? If you want money, produce a complete program with 386P+XGE and get payed for it, the program will get a wider distribution because all the XVD drivers produced and freely distributed will let people fully exploit the graphics power of their cards and better enjoy your program. Of course, if you customize a video driver you can add your name in the credits, but you cannot delete the other names! One of the problems with VESA games is that you have to find the driver for your card and install it properly, with XVD you just copy a file to the game directory or let the setup program find the driver for you. With xvd driver sources freely available, it is possible to devenlop lots of different variants for the same svga chipset getting the max from every board (i.e. some chipsets works faster if pixel transferts matches the bus size (byte,word or dword), if there is a driver for chipset xyz optimized for dword size and you want word size optimal performance, simply get the source code change some instructions and you get the max from your card). As you can see XVD is not a super-duper-can-do-anything thing it is just a simple interface to hardware with reasonable limitations. An XVD implementation in plain vga mode 13h may look ugly, but once you get multiple display pages, XVD is really good, and if you don't like how the XGE higher level code handles the card you can rewrite it without devenlop a new driver type. Chapter III: The driver header ; XVD XGE Video Driver ; Header format __XVD_SIGNATURE= 0 ; It be the four byte signature 'XVD0' ; XGE Video Driver TYPE ZERO, four byte file marker ; use it to see if the binary file is an XVD driver ; now here comes the driver base relative offsets ; of every function supported __XVDBiosCheck=4 ; driver-base relative pointer to XVDBiosCheck ; Returns carry clear if video bios is present ; sets vram video pages count into driver table ; and available display mode mask ; in: edi= XVD driver table , ebp= driver base offset ; (the dos-extender "interface" data is located ; always starting from code32 offset 0 ; (see head32.inc for more info) __XVDChipSetCheck=8 ; driver-base relative pointer to XVDChipSetCheck ; Returns carry clear if chipset is present ; sets vram video pages count into driver table ; and availabl;e display mode mask ; in: edi= XVD driver table , ebp= driver base offset ; currently BOTH of these must be successful ; to "get safe access" to the graphics extensions. ; ; If __XVDBiosCheck fails you should want the user ; that bios is not recognized but it is possible to ; test for the chipset and then try to set ; the video mode hoping the mode set values ; are not different. ; ; A future XGE release will try to use VESA functions ; to set the video mode if _XXVDBiosCheck fails ; and then if _XVDChipSetCheck is successful ; it will "unlock" the extensions thru direct chipset access. ; ; To use "extended" multi-page mode 13h you only have ; to check for the chipset (the bios entry is the same ; for all boards) but remember to include in the bios check ; the code needed to "unlock" the vga extensions. ; ; both __XVDBiosCheck and __XVDChipSetCheck ; must be called with: ; edi= XVD driver table ptr ; ebp= driver base address ; _XVDVPages,_XVDMappings,_XVDVModes and _XVDASize ; will be updated to what the driver supports. __XVDMode=12 ; driver-base relative pointer to XVDMode ; Set video mode ; eax=requested video mode ; edi= XVD driver table ptr ; ebp= driver base address ; returns carry clear if successful __XVDPage=16 ; driver-base relative pointer to XVDPage ; Set the current "accessible" 64k video page ; in: eax= video page number ; out: edi= LINEAR address of video page ; (subtract _Code32Base to this to get ; the code32 relative offset) ; The "accessible" video page is always 64kwide ; and is readable and writable. ; If you have a card using dual 32k cpu windows ; pair them into a "simulated" 64k one. ; If you have a card using single/dual 128k cpu windows ; simply "select a 64k block" into it (that's why __XVDPage ; returns a linear base address too) __XVDVisible=20 ; driver-base relative pointer to XVDVisible ; Set the base page of display buffer visible on screen ; in: eax= video page number __XVDOpen=24 ; driver-base relative pointer to XVDOpen ; Opens the "linear aperture" (maps all vram on cpu addresses) ; setting to the nearest aperture available on driver table ; (the 386video module must write on _XVDAperture ; the "first" AVAILABLE PHYSICAL ADDRESS ; (nor a code32 relative address neither ; a "virtual memory" linear address, this functions ; needs a "raw" physical address). ; edi=driver table, ebp=driver base address ; Returns CARRY CLEAR if successful ; And into _XVDAperture there will be the physical address ; the XVD driver decided to locate the linear aperture ; (it can be different from the initial value) ; then it will be up to you (using the 386power ; physical to code32 mapping functions) to se it up ; as code32 accessible memory __XVDClose=28 ; driver-base relative pointer to XVDCLose ; Closes the "linear aperture" ; edi=driver table ebp=driver base offset __XVDLineSize=32 ; driver-base relative pointer to XVDLineSize ; Set scanline width ; in: eax= requested scanline size ; edi=driver table ; ebp=driver base address ; out: nearest scanline size set into driver table ; RGB palette handling functions ; (identical to _Set1Pal,_Get1Pal,_Set256pal) __XVDSet1Pal=36 ; driver-base relative pointer to XVDSet1Pal __XVDGet1Pal=40 ; driver-base relative pointer to XVDGet1Pal __XVDSet256Pal=44 ; driver-base relative pointer to XVDSet256Pal __XVDCardType=48 ; driver-base relative pointer to ASCIIZ string ; max. 30 character long ; (use this in the "choose driver" list) __XVDProgrammer=52 ; driver-base relative pointer to ASCIIZ string ; with multiple lines of text,max. 40 char each ; (use the LF char (code 10h) to mark newlines) ; (extended info on driver) __XVDNotes=56 ; driver-base relative pointer to ASCIIZ string ; with multiple lines of text,max. 40 char each ; (use the LF char (code 10h) to mark newlines) ; of notes about the driver usage and supperted display ; cards. (detailed info) Appendix: Some further explanations about the XVD interface: Into XGE you will never see XVD if you don't want to, the only thing you have to do is select the driver, the initialization code will load it and let it self-initialize, is you want to make a cool setup program you can include a "self configure" option (the setup program loads the drivers and checks for bios and chipset using the driver detection functions), but ALWAYS include a "user driven configuration" option (some boards are hard to recognize for example my C&T 450 can pass the "bios check" for Realtek cards but it is different). For further info and explanations look into driver.txt, xvdriver.inc, head32.inc, 386video.txt, 386video.asm, 386video.inc, makefile and the XVD driver sources (for example chips450.asm) If everything else fails, try to call me on the following internet addresses knight@maya.dei.unipd.it but keep in mind that for most of 1995 i will be in the army (mandatory militar service here in Italy) so i won't access frequently my internet account on the Engineering Department at Padova. My plain mail address is at the end of tech.txt. Ciao, Lorenzo Micheletto knight@maya.dei.unipd.it N.B. If you want to extend the capabilities of the XVD drivers (new functions, etc, etc) set up a portable interface (not a thing good for your graphic card only) and call it 'XVD1' and so on, but before doing this look into x2ftp.oulu.fi to see if someone else did it before you, check if the already published release is good enough, if not, publish yours with a successive number (i.e. XVD2, XVD3, etc. etc.).